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ABSTRACT 



An object-oriented over-the-air service provisioning 
(OTASP) computer program is disclosed. The OTASP pro- 
gram is implemented in a client-server architecture, wherein 
a plurality of client programs operating, on client platforms 
in a customer service centers, optionally in diverse geo- 
graphical locations, communicate with the OTASP computer 
program. The OTASP computer program communicates 
with one or more mobile switching centers (MSCs) to 
process requests from the client programs and to request 
communication with mobile telephones using an over-the- 
air interface, in order to accomplish over-the-air service 
provisioning. 

18 Claims, 5 Drawing Sheets 
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METHOD AND APPARATUS FOR OVER- obtained. The service center establishes a provisioning com- 

THE-AIR SERVICE PROVISIONING OF A munication link with the mobile telephone through the SS7 

MOBILE TELEPHONE network and the mobile switching center (MSQ supporting 

the call. Using this communication link, the mobile tele- 

COPYR1GHT NOTICE/PERMISSION 5 phone can be provisioned over-the-air by wireless short 

message commands sent to the telephone, and using provi- 

A portion of the disclosure of this patent document sioning information sent by the mobile telephone back to the 

contains material which is subject to copyright protection. service center Qver (he commumca iion link. 

The copyright owner has no ° b ^ 0 ^ While the IS-683 standard specifies the basic messaging 

reproduction by anyone of the patent f^^^^ 10 t0 be supported by the mobile telephone and the wireless 

disclosure, as it appears in the Patent and Trademark Office ™ * OTA provisioning, it does not specify a 

patent file or records, but otherwise reserves al copyright levd archileclure P for the ^ ftware and ^terns 

nghts whatsoever. The following notice applies to the soft- * messaging. The 

ware and its interfaces as described below and in the M . .. J u -. . i a 

drawing hereto: Copyright <D 1998, ADC NewNet, Inc. All w P resem inventl0n addresses these *"*^ tural ^ 

Rights Reserved. SUMMARY OF THE INVENTION 

TECHNICAL FIELD OF THE INVENTION The present invention provides a method, system and 

software architecture facilitating over-the-air (OTA) service 
The present invention relates generally to mobile tele- provisioning (OTASP) of a mobile telephone, from a cus- 
phone systems, and more particularly to method and appa- 20 tQmer &cr/icc ceQter> tnroug h a mo bile switching center 
ratus for over-the-air service provisioning of a mobile tele- ^ MS q Qver the SS7 networkt According to one embodiment 
phone, of the invention, object-oriented OTASP software executes 

_ _ _ „ rT _ on a UNIX platform and communicates, on the one hand, in 

BACKGROUND OF THE INVENTION a TCp/lp p * ^ ^ ^ located at a remQte 

Prior to its activation and use in a wireless network, a 25 customer service center, and, on the other hand, using the 

mobile telephone must be provisioned for service. Provi- SS7 network, with the MSC By this architecture, the client 

sioning includes, at a minimum, programming the mobile software may send and receive messages and provisioning 

telephone with a telephone number, and programming the data to a mobile telephone supported by the MSC, through 

wireless network with the serial number and telephone 3(J the OTASP software and the SS7 network, 

number of the mobile telephone. Thus programmed, the According to another embodiment of the invention, mul- 

mobile telephone and wireless network are enabled to carry tiple instances of the OTASP software may be instantiated 

telephone calls between the mobile telephone and the public on the UNIX platform, wherein each instance supports a 

switched telephone network (PSTN). Provisioning may also different mobile telephone standard, such as CDMA and 

include programming the wireless network and mobile tele- 35 TDM A. Furthermore, each instance of the OTASP software 

phone to support one or more optional feature for the mobile may initiate multiple simultaneous sessions each supporting 

telephone, such as call forwarding, three-way calling, voice the provisioning of a different mobile telephone. In addition, 

messaging, short messaging and paging. the client-server architecture allows a plurality of clients to 

To date, provisioning/programming of a mobile telephone communicate with the OTASP software simultaneously, and 

has largely been done on the premises of the vendor or 40 allows such clients to be located in locations remote from 

distributor of the telephone. A data port on the mobile one another. 

telephone* used torcnnec^ DESCRIPTION OF THE DRAWING 
system that uploads provisioning data into the telephone, 

such as the telephone number assigned to the telephone, in FIG. 1 illustrates a wireless network and its interconnec- 

order to program it for use in the wireless network. 45 tion with the SS7 signaling network and the public switched 

Alternatively, the telephone is programmed through its key telephone network. 

pad. This approach, while sound and secure, requires the p IG 2 illustrates the over-the-air service provisioning 

undesirable step of programming/provisioning the mobile S y St em of the present invention deployed for operation in a 

telephone before it can be delivered to a subscriber. The telephone system. 

ability to deliver a mobile telephone directly to a subscriber 50 pjQ 3 iliustrates thc hardware/software platform for the 

without first having to proven the telephone provides over _ lhe _ air service provisioning system 0 f the present 

obvious advantages in the speed of delivery to the mvermon 

subscriber, and the potential to simplify the provisioning ' . 

process. Also, the ability to re-provision a mobile telephone FIG. 4 is a schematic representation of the operation of 

over-the-air without returning the phone to a service center 55 ^ over-the-air service provisioning server software of the 

also has obvious advantages. P resenl inventl0n - 

An alternative over-the-air (OTA) service provisioning FIG. 5 is a schematic representation of the over-the-air 

(OTASP) approach has thus been defined by a standard body service provisioning software handling multiple sessions 

so that a mobile telephone can be provisioned over-the-air according to the present invention. 

using the wireless network. The requirements of this stan- 60 FIG. 6 illustrates the messaging interaction of the chent- 

dard are defined in IS-683 (also known as PN-3889), pub- server over-the-air service provisioning system of the 

lished by the Telecommunications Industry Association present invention. 

(T.I.A.), the entire contents of which are hereby incorporated DETAILED DESCRIPTION OF THE 

herein by reference. In its most basic form, this approach INVENTION 
provides that a mobile telephone is temporarily provisioned 65 

to allow a subscriber using the telephone to call a customer In the following detailed description of the preferred 

service center, through which long-term provisioning can be embodiments, reference is made to the accompanying draw- 
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ings that form a part hereof, and in which are shown by way 
of illustration specific embodiments in which the invention 
may be practiced. It is understood that other embodiments 
may be utilized and structural changes may be made without 
departing from the scope of the present invention. 

Architecture 

Referring to FIG. 1 there is illustrated a wireless network 
10 and its interconnection with the SS7 signaling network 12 
and the public telephone switching network (PSTN) 14. 
Wireless network 10 includes a mobile switching center 
(MSG) 16, which is interconnected with the SS7 signaling 
network 12 through a SS7 data link 18, and to the PTSN 14 
over trunk line(s) 20. Wireless network 10 further includes 
a plurality of RF units 22, which are connected to the MSC 
16 over data links 24. The operation of this configuration is 
conventional, with telephone calls being routed between 
mobile telephone units 26 and the PTSN 14 through MSC 16 
and RF units 22. 

Referring to FIG. 2 there is illustrated in simplified form 
an over-the-air (OTA) client-server provisioning system 30, 
deployed in a telephone network, according to the present 
invention. System 30 includes a server platform 32, main- 
taining over-the-air service provisioning (OTASP) software 
34, and one or more client platforms 36, executing client 
software 38. Client platforms 36 are located in a customer 
service center (CSC) 40 and constitute part of respective 
customer service stations 44. A PBX 42 is located at the 
service center 40, and interfaces the PTSN 14 to a handset/ 
headset 46 at each customer service station (connection not 
shown). Optionally, PBX 42 is also coupled to each client 
platform 36. A network connection 48 connects platforms 36 
and platform 32. Network connection 48 preferably uses a 
TCP/IP protocol and may take the form of a wide area 
network connection, a local area network connection, or a 
connection through the Internet Platform 32 is coupled to 
MSC 16 over SS7 data links 18 and SS7 network 12. 
Platform 32 can be co-located in the same building as 
platforms 36, or can be located remotely therefrom. The 
platform 32 of the example embodiment described herein is 
a single server computer system, such as a SUN Solaris™ 
server, with a single operating system. 

Referring to FIG. 3, there is illustrated in simplified form 
platform 32 and the OTASP software 34 operative thereon. 
Platform 32 includes computer hardware 50, preferably, but 
not limited to, a high-performance workstation, with a 
multitasking operating system 52, such as UNIX or Win- 
dows NT. OTASP software 34 is an object-oriented appli- 
cation executing on platform 32. Platform 32 is also pref- 
erably configured with one or more SS7 I/O circuits to 
connect platform 32 to the SS7 network. 

Referring to FIG. 4, there is illustrated in conceptual 
diagrammatic form a representation of multiple instantia- 
tions of OTASP software 34 (denoted 34-1, 34-2, 34-/i in 
FIG. 4), each executing simultaneously on platform 32. 
Each of OTASP software 34 communicates with one or 
more client platforms 36, and more specifically client soft- 
ware or program 38 executing on platforms 36. In the 
example embodiment illustrated herein, each instance of 
OTASP software 34 (34-1, 34-2, 34-w) is configured to carry 
out the provisioning of a wireless network of a specific type. 
For example, a first instance 34-1 is configured to provision 
mobile telephones 26 in a CDMA-based wireless network, 
while another instance 34-2 is configured to provision 
mobile telephones 26 in a TDMA-based wireless network. 
As described below in more detail, each instance of OTASP 
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software 34 car handle multiple provisioning sessions 
simultaneously, each controlled by the, same or a different 
one of client programs 38, wherein each client program 38 
resides on a client platform 36, and wherein the client 

5 platforms 36 may be located physically or geographically 
apart from one another. Furthermore, it is possible that each 
instance of OTASP software 34 is programmed to commu- 
nicate with one or more different MSCs 16. Accordingly, 
the embodiment of the invention herein described advanta- 

10 geously allows a single server platform 32, running multiple 
instances of OTASP software 34, to handle provisioning of 
mobile telephones 26 of different types, operating using a 
different wireless mode (e.g., TDMA, CDMA or others), 
from client programs 38 located in diverse geographical 

15 locations. Thus, a wireless service provider operating dif- 
ferent types of wireless networks can handle all OTA pro- 
visioning for their networks with a single server platform 32 
and package of OTASP software 34. 
In the example embodiment herein described, OTASP 

20 software 34 is an object-oriented program, for example 
written in the C++ computer language. Client program 38 
may also be an object-oriented program. However, the 
client-server software of the invention is not limited to 
implementation in an object-oriented language, or to imple- 

25 mentation in the C++ language. 

In one example embodiment of the invention, a customer 
service representative is positioned at each customer service 
station 44. The customer service representative receives 
telephone calls from subscribers seeking to provision their 

30 mobile telephone 26, either upon initial use of the mobile 
telephone 26 or at a later point in time when, for example, 
a change in service options or carrier is desired. The cus- 
tomer service representative can provision the subscriber's 
mobile telephone 26 over-the-air using the client program 38 

35 and an instance of OTASP software 34, which in turn 
operates in conjunction with the MSC 16. As illustrated in 
simplified schematic form in FIG. 5, each instance of 
OTASP software 34 can simultaneously process a plurality 
of sessions 50 (denoted 50-1, 50-2, 50-/J in FIG. 5). Each 

40 session 50, as described in more detail below, handles the 
provisioning of a mobile telephone 26, as directed by a client 
program 38. 

OTASP software 34 and MSC 16 (and in particular the 
computers associated therewith) are designed to support the 

45 IS-683 standard, allowing for OTA provisioning of a mobile 
telephone 26, as discussed in more detail below. A client 
program 38 includes a user interface for interacting with 
customer service representative, allowing the representative 
to control the provisioning process from the customer ser- 

50 vice station 44. Alternatively, client program 38 may be 
configured to include a voice response system and allow that 
provisioning can be conducted automatically in whole or in 
part, by automated interaction with a subscriber over the 
subscriber's mobile telephone 26 wherein a subscriber may 

55 enter selections using the keypad of the mobile telephone, or 
by voice commands interpreted by the client program 38. 

Operation 

Overview 

60 In order to provision mobile telephones 26 using the 
system of the present invention, each client platform 36: 1) 
establishes a network connection with the OTASP platform 
32; 2) sends a number of request messages to the OTASP 
platform 32; and 3) processes response messages from the 

65 OTASP platform 32. Through this interaction, the client 
platform 36 can request information from and provide 
provisioning instructions and data from/to MSC 16 and 
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mobile telephones 26. This interaction thus allows a mobile 
telephone 26 to be provisioned pursuant to IS-683. As noted 
above, in the example embodiment of the invention herein 
described, communication between the client platform 36 
and the OTASP platform 32 is carried out using a TCP/IP 
protocol, although the invention is in no way limited in this 
aspect. 

FIG. 6 illustrates the messaging flow for communications 
between client program 38, OTASP software 34, MSC 16 
and mobile telephone 26. Requests originate with the client 
program 38, and are responded to by OTASP software 34. If 
a request from the client program 38 requires interaction 
between the OTASP software 34 and the MSC 16, the 
OTASP software 34 and MSC 16 exchange request -response 
messages prior to the response from the OTASP software 34 
to the client program 38. Requests to the MSC 16 which 
require an exchange with a mobile telephone 26 result in a 
request-response exchange between MSC 16 and the mobile 
telephone 26. 
Session Initiation 

To initiate a session 50 on an instance of the OTASP 
software 34, an open session request message is sent by the 
client program 38 to the OTASP software 34. The client 
program 38 assigns a client session ID to the session, and 
forwards the ID to the OTASP software 34. This client 
session ID is used for all subsequent messages regarding this 
session. 

Upon receipt of this request message, OTASP software 34 
allocates the resources needed (e.g. memory, etc.) for this 
session. Upon resource allocation a session response is 
returned, which includes a server session ID. Both the client 
program 38's origination ID and this server ID must be used 
in all subsequent messages for identification. In the example 
embodiment herein presented, each message includes, at a 
minimum, the client session ID, the server session ID, and 
a result parameter indicating whether the operation was 
successful or not (i.e., if the resources could be allocated, 
etc.) If the result parameter indicates a success, the message 
interaction between the client program 38 and the OTASP 
software 34 continues for this session. If the result indicates 
failure, the OTASP software 34 procedure is preferably 
terminated. 
Data Connectione 

Once a session is established, the server program 38 ends 
a data connection request to the OTASP software 34, which 
in turn establishes a data connection with an MSC 16. The 
data connection request preferably includes, the client ID, 
server ID, and a temporary routing number (TRN) that the 
client program 38 supplies to the OTASP software 34. The 
TRN is obtained at the service center 40 from the incoming 
call from the subscriber seeking provisioning of a mobile 
telephone 26. The TRN is obtained from the digital routing 
information forwarded over the PSTN 14 in connection with 
the call from the subscriber. The TRN can be automatically 
extracted from the line from the PTSN 14 and supplied to 
client program 38, or it can be obtained by a service 
representative by viewing a data display unit at the repre- 
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an smdpp message which specifies the following param- 
eters: 

1) the mobile telephone's electronic serial number (ESN); 

2) the mobile identification number (MIN — mobile sub- 
scriber phone number in IS41-C) which is currently in 
the mobile telephone 26's permanent memory; 

3) the ID for the MSC 16; and 

4) the MSC's authentication capabilities. 

Upon successful receipt of the smdpp message, the 
OTASP software 34 sends an SMDPP message that instructs 
the MSC to release the TRN. According to this example 
embodiment, this second SMDPP contains the following 
parameters, as do subsequent SMDPP messages: 

1) a SMS_BearerData field (with length set to zero); 

2) a SMS_TeleServiceIndentifier field (with length set to 
zero); 

3) an ActionCode set to Release TRN to release the TRN 
assigned to the mobile telephone 26; 

4) an electronic serial number (ESN) set to value received 
from MSC; 

5) a MIN set to activation MIN assigned by OTASP 
software 34; and 

6) a Servicelndicator set to [Service type — such as 
CDMA] OTASP service. 

The MSC 16 responds to this message with an smdpp 
message which contains no parameters. 

Once the communication with the MSC 16 is finished, the 
OTASP software 34 sends a data connection response to the 
client program 38 specifying: 

1) the client session ID assigned to the session by the 
client program 38; 

2) the server session ID assigned to the session by the 
OTASP software 34 in Session Initiation; 

3) a result that indicates whether this operation was 
successful or not; 

4) the mobile telephone's electronic serial number; 

2) the MIN which is currently in the mobile telephone 
26's permanent memory; 

3) an ID for the MSC 16; and 

4) the MSC's authentication capabilities. 
If the result parameter indicates a success, the message 

interaction between the client program 38 and the OTASP 
software 34 continues for this session. If the result parameter 
indicates failure, the client program 38 means terminate the 
procedure. 

Communicating with the MSC and Mobile 
Telephone 

Protocol Capability 

The client program 38 uses the protocol capability request 
message to request the mobile telephone 26 to send back its 
capabilities. This message is sent to the OTASP software 34 
which forwards the request through the MSC 16 to the 
mobile telephone 26. This data message and the response, 
are encoded in IS-683 format in the SMS_BearerData 
portion of the SMDPP and smdpp. When the OTASP soft- 



sentative's customer service station 44 in the service center 60 ware 34 receives the request message, it encodes an IS-683 



40 or by other means. 

Using the TRN, the OTASP software 34 looks up the 
MSC routing information in a temporary routing number 
table maintained on the platform 32. Using this routing 
information, the OTASP software 34 sends an SMDPP 65 
message requesting the MSC 16 to communicate with the 
OTASP platform 32 for the call. The MSC 16 responds with 



message and sends it to the MSC 16 in an SMDPP, The MSC 
16 sends the request to the mobile telephone 26. When the 
MSC 16 receives a reply, it sends it in a smdpp message to 
the OTASP software 34. When the OTASP software 34 
receives the smdpp from the MSC 16, it builds a protocol 
capability response and sends it to the client program 38. If 
the System Selection for Preferred Routing (SSPR) feature 
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of IS-683 is supported, the SSPR procedures will take place SSPR Configuration 

during the download message. The protocol capability The goal of system selection for preferred roaming 

response indicates the features supported by the mobile (SSPR) is for the mobile telephone 26 to acquire the most 

telephone 26. preferred system using the information from the preferred 

System Programming Lock (SPL) Validation 5 roaming list stored in the mobile telephone 26. Before the 

The SPL validation procedure may be performed if the roaming list can be downloaded, SSPR configuration mes- 

protocol capability response from the mobile telephone 26 sages are exchanged between the OTASP software 34 and 

indicates that the mobile telephone 26 supports the program- the mobile telephone 26 to determine the amount of memory 

ming lock feature. The SPL protects access to the mobile that the mobile telephone 26 has available to store the 

telephone 26 programming module which contains the to preferred roaming information. After this SSPR Configura- 

NAM indicators and parameters that can be assigned values tion procedure is completed, the SSPR download procedure 

during over-the-air service provisioning. The SPL parameter can take place. The SSPR configuration request contains the 

contains the Service Programming Code (SPC) used for SSPR configuration request data which will be encapsulated 

unlocking the mobile telephone 26 parameters for program- within the SMS_BearerData field, 

ming or reprogramming. The SPL request requests data 15 When the OTASP software 34 receives the request 

which will be encapsulated within SMS_BearerData. message, it sends an SMDPP message to the MSC 16. The 

When the OTASP software 34 receives the request SMDPP contains the request data encapsulated in an IS-683 

message, it sends an SMDPP message to the MSC 16. The encoded message. 

SMDPP contains an IS-683 encoded message with the The MSC 16 in turn sends the request to the mobile 

request. The MSC 16 sends the request to the mobile 20 telephone 26. When the MSC 16 receives a reply, it sends it 

telephone 26. When the MSC 16 receives a reply, it sends the in an smdpp message to the OTASP software 34. The smdpp 

reply to the OTASP software 34 in an smdpp message. The contains, in the MS_BearerData field, the OTASP data 

smdpp contains, in the SMS_BearerData field, the OTASP message received from the mobile telephone 26 over-the-air 

data message received from the mobile telephone 26 over- interface. 

the-air interface. 25 When the OTASP software 34 receives the smdpp from 

When the OTASP software 34 receives the smdpp from the MSC 16, it builds an SSPR configuration response and 

the MSC 16, it builds the SPL response and sends it to the sends it to the client program 38. The SSPR configuration 

client program 38. The SPL response contains the SPL response message contains the requested parameters of the 

response data returned in SMS_BearerData received from configuration response data along with a result code for each 

the MSC 16. 30 requested parameter returned in SMS_BearerData received 

Configuration from the MSC 16. The client program 38 examines the result 

The client program 38 sends a configuration request to codes returned for each parameter. If any of the result codes 

request the mobile telephone 26 to send relevant data indicate a failure, the OTAF procedure may be terminated. 

currently stored in its permanent memory. The messages SSPR Download 

goes through the OTASP software 34 and the MSC 16. The 35 ^The-purpose of ihVSystem Select 

configuration request contains a configuration request data ^ingXS§PR):List -downloa'd:is-ta loadthermobile -telephone 26*^ 

which will be encapsulated within SMS_BearerData. with^te-prefeir^ SSERQ 

When the OTASP software 34 receives the request Gonfiguration:message exchang e . ^tw eenjjhe'OTASP softer] 

message, it encodes an IS-683 message and sends it to the < warer34^FrMh^mobae~lelepr^ 

MSC 16 in an SMDPP. 40*downloTd procedure~takes-place.- The SSPR Downloath 

The MSC 16 receives a response from the mobile tele- ,requesrcomains:SSPR downlo 

phone 26 and forwards it to the OTASP software 34 in an encapsulated withm:SMS^earerDatar^ 

smdpp. The smdpp contains the OTASP data message When the OTASP software 34 receives the request 

received from the mobile telephone 26 over the air interface. message, it sends an SMDPP message to the MSC 16. In the 

The configuration response includes the configuration 45 SMS_BearerData field, 

response data from the mobile telephone returned in SMS_ The MSC 16 sends the request to the mobile telephone 26. 

BearerData received from the MSC 16. When the MSC 16 receives a reply, it sends the reply to the 

Download OTASP software 34 in an smdpp message. The smdpp 

When the client program 38 is ready to activate the mobile contains the OTASP data message received from the mobile 

telephone 26, it sends a download request message to the 50 telephone 26 over-the-air interface. 

OTASP software 34. The message contains data that will be When the OTASP software 34 receives the smdpp from 

downloaded by the mobile telephone 26 into its temporary the MSC 16, it builds an SSPR Download response and 

memory. The download request contains the download sends it to the client program 38. The response contains the 

request data which will be encapsulated within the SMS__ SSPR download response data returned in SMS___ 

BearerData field sent to the MSC 16 by the OTASP software 55 BearerData received from the MSC 16. 

34, Commit 

When the OTASP software 34 receives the request If the download procedure was successful, the client 

message, it encodes an IS-683 message and sends it to the program 38 sends the commit request message to direct the 

MSC 16 in an SMDPP. mobile to transfer all the data that has been downloaded 

The MSC 16 receives a response from the mobile tele- 60 during the current session to permanent memory. This 

phone 26 and forwards it to the OTASP software 34 in an IS-683 message is encapsulated within the SMS_ 

smdpp. The smdpp contains the OTASP data message BearerData. When the OTASP software 34 receives the 

received from the mobile telephone 26 over-the-air inter- request message, it encodes an IS-683 message and sends it 

face. to the MSC 16 in an SMDPP. 

The download response to the client program 38 from the 65 The MSC 16 receives a response from the mobile tele- 

OTASP software 34 contains the download response data phone 26 and forwards it to the OTASP software 34 in an 

returned in the SMS_BearerData field from the MSC 16. smdpp. The smdpp contains the IS-683 encoded data mes- 



03/20/2002, EAST version: 1.02.0008 



6,144,849 

9 10 

sage received from the mobile telephone 26 over-the-air OTASP software 34 in as smdpp message. The smdpp 

interface. The commit response contains the commit includes the OTASP data message received from the mobile 

response data returned in SMS_BearerData received from telephone 26 over-the-air interface, 

the MSC 16. When the OTASP software 34 receives the smdpp from 

Registration Request 5 the MSC 16, it builds an MS Key response and sends it to 

After the commit procedure has completed successfully, a the client program 38. The response contains the MS Key 

new MIN has been programmed into the mobile telephone response data returned in SMS_BearerData received from 

26. This new MIN must be transferred to the MSC 16. Since the MSC 16. 

the phone is already powered on, the MSC 16 must initiate Key Generation 

the registration to the home location register (HLR) with the Before the client program 38 sends the Key Generation 

new MIN and de -registration with the old MIN (if successful Request, it should have received the MS Key response 

registration had occurred with the old MIN). The registration message containing a result code indicating a successful 

request contains the new MIN that is now programmed into operation. The Key Generation request message contains 

the mobile telephone 26. Key generation request data which will be encapsulated 

When the OTASP software 34 receives the request SMS JearerData 

message, it sends an SMDPP message to the MSC 16. Tlie 15 When the OTASP software 34 receives the request 

CMnD 6 D ' . & message, it creates and sends a IS-683 encoded message to 

;>Mur v contains. ^ the MSC lfi tha( ests lhe mobne telephone 26 to 

1) an ActionCode set to Initiate Registration Notification; g enerate A-key. 

2) the ESN set to the value received from MSC 16; -j^e ^SC 16 sends the message to the mobile telephone 

3) the MIN set to the activation MIN assigned by OTASP 2 o 26. When the MSC 16 receives a reply, it sends it to the 
software 34; and OTASP software 34 in an smdpp message. The smdpp 

4) a new MIN received from client program 38; and contains the OTASP data message received from the mobile 

5) a Servicelndicator set to the appropriate service type telephone 26 over-the-air interface. 

(e.g. CDMA). When the OTASP software 34 receives the smdpp from 

The MSC 16 responds with an smdpp message which 25 the MSC 16, it builds a Key Generation response and sends 

contains no parameters. The OTASP software 34 sends a it to the client program 38. The response contains the Key 

response to the client program 38. The response indicates generation response data returned in SMS JearerData 

whether the operation was successful or not (i.e., if the received from the MSC 16. 

TCAP queries were responded to successfully or if a reject Re -Authentication 

message was received). 30 The purpose of the Re- Authentication procedure is to 

New MIN Notification Request initiate the Voice Privacy and/or Signaling Message Encryp- 

After successfully assigning a new MIN to a mobile tion (VP/SME) features during an OTASP call. This proce- 

telephone 26, the client program 38 may determine that the dure can occur following the successful completion of an 

OTASP software 34 should be notified of the newly assigned A-Key exchange (MS Key) procedure or a Shared Secret 

MIN. The client program 38 would send the registration 35 Data (SSD) update procedure. The re-authentication proce- 

request message, which contains the new MIN that is now dure does not program any new information into the mobile 

programmed into the mobile telephone 26, to the OTASP telephone 26. The re-authentication request contains the 

software 34. Re -Authentication request data which will be encapsulated 

When the OTASP software 34 receives the request within SMS_BearerData. 

message, it sends an SMDPP message to the MSC 16. The 40 When the OTASP software 34 receives the request 

SMDPP contains an ActionCode set to record a new MIN, message, it sends an SMDPP message to the MSC 16. The 

a MIN set to the activation MIN assigned by the OTASP SMDPP contains IS-683 encoded message and the ESN set 

software 34, and a new MIN received from client program to the value received from the MSC in the data connection 

38 procedure described above., and the activation MIN 

The MSC 16 responds with an smdpp message which 45 assigned by the OTASP software 34. 

contains no parameters. The MSC 16 sends the request to the mobile telephone 26. 

The OTASP software 34 sends a response to the client When the MSC 16 receives a reply, it sends it to the OTASP 

program 38. The response contains an indication whether software 34 in an smdpp message. The smdpp contains the 

this operation was successful or not (i.e., if the TCAP OTASP data message received from the mobile telephone 26 

queries were responded to successfully or if a reject message 50 over-the-air interface. 

was received). When the OTASP software 34 receives the smdpp from 

Ms K e y the MSC 16, it builds a Re-Authentication response and 

The A-Key exchange procedure is invoked to exchange sends it to the client program 38. The response contains the 

key parameters between the authentication center and the Re-Authentication response data, 

mobile telephone 26. For this purpose, the client program 38 55 Session Closure 

sends an MS Key Request to the OTASP software 34. The A service provisioning session must always be closed 

MS Key request contains the MS Key request data which with a close session request so that the OTASP software 34 

will be encapsulated within SMS_BearerData. can release the resources that were allocated. A session 

When the OTASP software 34 receives the request should be closed when a service provisioning session has 

message, it sends a request for key-exchange generate keys 60 successfully completed, the client program 38 determines 

to an authentication center. After receiving the key values that a response received from the OTASP software 34 or the 

from the authentication center, the OTASP software 34 MSC 16 has failed, or the client program 38 is no longer able 

encodes an IS-683 message and sends it to the MSC 16 to to proceed with this session. When a session is closed, all 

be sent to the mobile telephone 26 in the SMS_BearerData unacknowledged messages (smdpps) from the MSC 16 will 

geld. 65 be discarded. When the OTASP software 34 receives the 

The MSC 16 sends the message to the mobile telephone request from client program 38, it releases the resources of 

26. When the MSC 16 receives a reply, it sends it to the the session and sends back a response. 
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Session Termination 

Normally, the client program 38 terminates a service 
provisioning session with a message to the OTASP software 
34. However, the OTASP software 34 will terminate a 
session if no activity occurs over the interface or if the 5 
session is open too long. By default, the OTASP software 34 
allows a session to remain open for 80 seconds. This length 
of time can be changed with a command sent by the client 
program 38. If a session is still open after the configured 
amount of time, the OTASP software 34 sends a session 10 
termination message. Upon termination of the session, the 
OTASP software 34 releases all resources that were allo- 
cated for the session and discards all unacknowledged 
messages (smdpps) from the MSC 16. 
Alternate Embodiments 15 

Hie present invention is in no way limited to the example 
embodiment described herein. As noted above, the invention 
is not limited to object-oriented software. Nor is it limited to 
any particular type of hardware or operating system 
platforms, or client-server or network architecture. For 20 
example, the client-server interaction may be performed 
over the Internet using a web-browser/server/Java applica- 
tion. Moreover, the messaging system of the invention may 
also be implemented in alternate ways without departing 
from the scope of the invention. Furthermore, the software 25 
of the invention may also be implemented in whole or in part 
in hardware, and vice versa. 
Conclusion 

Thus, the example embodiment of the invention described 
above provides a client-server architecture and messaging 30 
interface for over-the-air service provisioning of mobile 
telephone services using the IS-683 standard. The embodi- 
ment of the invention herein described advantageously 
allows a single server platform 32, running multiple 
instances of OTASP software 34, to handle provisioning of 35 
mobile telephones 26 of different types, operating using a 
different wireless mode (e.g., TDMA, CDMA or others), 
from client programs 38 located in diverse geographical 
locations. Thus, a wireless service provider operating dif- 
ferent types of wireless networks can handle all OTA pro- 40 
visioning for their networks with a single server platform 32 
and package of OTASP software 34. 

We claim: 

1. An over-the-air service provisioning (OTASP) system 
for provisioning service for a mobile telephone through a 45 
mobile switching center (MSC) communicating with the 
mobile telephone over a wireless network, comprising: 
a server platform having a single server computer system 
connected for communication to at least one MSC over 
a SS7 signaling network; 50 
one or more instances of an OTASP computer program 
executing on the server platform, wherein each instance 
handles OTASP for a different type of wireless service; 
a plurality of client platforms; 55 
at least one client computer program executing on each 

client platform; 
the client computer program and the OTASP computer 
program connected over a computer network in a 
client-server architecture; 60 
each instance of OTASP computer program supporting 
one or more OTASP sessions, wherein each session is 
initiated by one of the client programs, and wherein 
each session includes the steps of: 
a) the client program sending a request to the instance 65 
of the OTASP computer program over the computer 
network; 



b) in response to the request from the client program, 
the OTASP computer program sending a request to a 
MSC over the SS7 signaling network; 

c) in response to the request from the OTASP computer 
program, the MSC sending a request to the mobile 
telephone over-the-air; 

d) in response to the request from the MSC, the mobile 
telephone sending a reply to the OTASP computer 
program over-the-air; 

e) in response to the reply from the mobile telephone, 
the MSC sending a reply to the OTASP computer 
program over the SS7 signaling network; and 

0 in response to the reply from the MSC, the OTASP 
computer program sending a reply to the client 
program over the computer network; and 
wherein the requests and responses sent between the 
client computer program, the OTASP computer pro- 
gram and the MSC accomplishes the service provision- 
ing of a mobile telephone over-the-air. 

2. A system according to claim 1 further wherein at least 
two of the client platforms are located at geographically 
remote locations. 

3. A system according to claim 1 further wherein the 
server platform is connected to a plurality of MSC's through 
one or more SS7 signaling networks. 

4. A system according to claim 1 wherein each instance of 
the OTASP computer program execute on the server plat- 
form simultaneously. 

5. A system according to claim 4 wherein each instance of 
the OTASP computer program handles a plurality of ses- 
sions simultaneously. 

6. A system according to claim 1 wherein the service type 
is CDMA or TDMA. 

7. An over-the-air service provisioning (OTASP) com- 
puter software product, comprising: 

object-oriented OTASP computer software encoded on a 
machine readable media, the OTASP computer soft- 
ware executable on a server platform to form one or 
more instances of an OTASP object-oriented computer 
program, wherein each instance of the OTASP com- 
puter program instance handles OTASP for a different 
type of wireless service, and wherein each instance of 
OTASP computer program executes on the server plat- 
form and supports one or more OTASP sessions, 
wherein each session includes the steps of: 

a) receiving a client request generated by a client 
connected to the server; 

b) in response to the client request, sending a request to 
a MSC using a SS7 signaling protocol, wherein the 
request includes data to be used by the MSC to 
communicate with a mobile telephone over-the-air; 

c) receiving reply from the MSC in a SS7 signaling 
protocol, wherein the reply from the MSC includes 
data obtained from a mobile telephone over-the-air; 
and 

f) in response to the reply from the MSC, sending a 
reply to the client; and 

wherein the requests and responses sent between the 
client and the instance of the OTASP computer pro- 
gram accomplish the service provisioning of a mobile 
telephone over-the-air. 

8. A system according to claim 7 wherein each instance of 
the OTASP computer program execute on the server plat- 
form simultaneously. 

9. A system according to claim 7 wherein each instance of 
the OTASP computer program handles a plurality of ses- 
sions simultaneously. 
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10. A system according to claim 9 wherein the service 
type is CDMA or TDMA. 

11. A system according to claim 9 wherein the server 
platform includes a single server computer system. 

12. A system according to claim 7 wherein each session 5 
communicates with a different client. 

13. A method for over-the-air service provisioning 
(OTASP) of a mobile telephone through a mobile switching 
center (MSC) which communicates with the mobile tele- 
phone over a wireless network, comprising the steps of: 10 

executing one or more instances of an OTASP computer 
program on server platform connected in a client-server 
configuration with a plurality of client platforms, and to 
at least one MSC over a SS7 signaling network, 
wherein each instance handles OTASP for a different 15 
type of wireless service and supports one or more 
OTASP sessions, wherein each session includes the 
steps of: 

a) receiving a client request generated by a client 
connected to the server; 20 

b) in response to the client request, sending a request to 
a MSC using a SS7 signaling protocol, wherein the 
request includes data to be used by the MSC to 
communicate with a mobile telephone over-the-air; 



c) receiving reply from the MSC in a SS7 signaling 
protocol, wherein the reply from the MSC includes 
data obtained from a mobile telephone over-the-air; 
and 

f) in response to the reply from the MSC, sending a 
reply to the client; and 
wherein the requests and responses sent between the 
client and the instance of the OTASP computer pro- 
gram accomplish the service provisioning of a mobile 
telephone over-the-air. 

14. A method according to claim 13 wherein each instance 
of the OTASP computer program execute on the server 
platform simultaneously. 

15. A method according to claim 13 wherein each instance 
of the OTASP computer program handles a plurality of 
sessions simultaneously. 

16. A method according to claim 14 wherein the service 
type is CDMA or TDMA. 

17. A method according to claim 13 wherein each session 
communicates with a different client. 

18. A method according to claim 13 wherein the server 
platform includes a single server computer system. 
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